Hypermedia management system

ABSTRACT

A system supplies links between objects. A link service receives a link request from a client. The request identifies a source object. The link service aggregates links from link providers for which the source object is a source of the links, and provides the aggregated links to the client.

BACKGROUND OF THE INVENTION

[0001] The present invention relates to hypermedia links. Morespecifically, the present invention relates to managing hypermedia linksbetween objects.

[0002] A number of different databases will first be discussed, althoughit will be appreciated that the objects need not reside in a database atall. In conventional relational databases that can be used to store theobjects, all data are stored in named tables. The tables are describedby their features. In other words, the rows of each table contain itemsof identical type, and the definitions of the columns of the table(i.e., the column names and the data types stored in the column)describe the attributes of each of the instances of the object. Byidentifying its name, its column names and the data types of the columncontents, a table is completely described. Queries to a relational database are formulated in a query language. One such language is SQL(Structure Query Language) which is widely used in commercial relationaldata base systems. The data types offered by SQL can be classified ascharacter arrays (names), numbers, and data types related to date andtime. Tables can be modified or combined by several operations ofrelational algebra such as the application of Boolean operators,projection (i.e. selection of columns) or the Cartesian product.

[0003] Relational databases offer several advantages. Database queriesare based on a comparison of the table contents. Thus, no pointers arerequired in relational databases, and all relations are treateduniformly. Further, the tables are independent (they are not related bypointers), so it is easier to maintain dynamic data sets. The tables areeasily expandable by simply adding new columns. Also, it is relativelyeasy to create user-specific views from relational databases.

[0004] There are, however, a number of disadvantages associated withrelational databases as well. For example, access to data by referenceto properties is not optimal in the classical relational data model.This can make such databases cumbersome in many applications.

[0005] Another recent technology for database systems is referred to asobject oriented data base systems. These systems offer more complex datatypes in order to overcome the restrictions of conventional relationaldatabases. In the context of object oriented data base models, an“object” includes both data and the methods which can be applied to theobject. Each object is a concrete instance of an object class definingthe attributes and methods of all its instances. Each instance has itsunique identifier by which it can be referred to in the database.

[0006] Object oriented databases operate under a number of principles.One such principle is referred to as inheritance. Inheritance means thatnew object classes can be derived from another class. The new classesinherit the attributes and methods of the other class (the super-class)and offer additional attributes and operations. An instance of thederived class is also an instance of the super-class. Therefore, therelation between a derived class and its super-class is referred to asthe “isA” relation.

[0007] A second principle related to object oriented databases isreferred to as “aggregation.” Aggregation means that composite objectsmay be constructed as consisting of a set of elementary objects. A“container object” can communicate with the objects contained therein bytheir methods of the contained objects. The relation between thecontainer object and its components is called a “partOf” relationbecause a component is a part of the container object.

[0008] Yet another principle related to object oriented databases isreferred to as encapsulation. According to encapsulation, an applicationcan only communicate with an object through messages. The operationsprovided by an object define the set of messages which can be understoodby the object. No other operations can be applied to the object.

[0009] Another principle related to object oriented databases isreferred to as polymorphism. Polymorphism means that derived classes mayre-define methods of their super-classes.

[0010] Objects present a variety of advantages. For example, operationsare an important part of objects. Because the implementations of theoperations are hidden to an application, objects can be more easily usedby application programs. Further, an object class can be provided as anabstract description for a wide variety of actual objects, and newclasses can be derived from the base class. Thus, if an applicationknows the abstract description and using only the methods provided by,the application can still accommodate objects of the derived classes,because the objects in the derived classes inherit these methods.However, object oriented data bases are not yet as widely used incommercial products as relational databases.

[0011] Yet another database technology attempts to combine theadvantages of the wide acceptance of relational data bases and thebenefits of the object oriented paradigm. This technology is referred toas object-relational database systems. These databases employ a datamodel that attempts to add object oriented characteristics to tables.All persistent (database) information is still in tables, but some ofthe tabular entries can have richer data structure. These datastructures are referred to as abstract data types (ADTs). An ADT is adata type that is constructed by combining basic alphanumeric datatypes. The support for abstract data types presents certain advantages.For example, the operations and methods associated with the new datatype can be used to index, store, and retrieve records based on thecontent of the new data type.

[0012] Some conventional object-relational databases support an extendedform of SQL, sometimes referred to as ObjectSQL. The extensions areprovided to support the object model (e.g., queries involving objectattributes). However, these object-relational databases are stillrelational because the data is stored in tables of rows and columns, andSQL, with some extensions, is the language for data definition,manipulation, and query. Both the target of a query and the result of aquery are still tables. The extended SQL language is often still theprimary interface to the database. Therefore, there is no direct supportof host object languages and their objects. This forces programmers tocontinue to translate between objects and tables.

[0013] Thus, in prior object-relational databases, an object can bequeried for in terms of the object's fields, rather than using therelational database column names.

[0014] However, a number of problems exist with respect to conventionaluser interface (UI) technology for object-relational technology andother databases or environments (other than databases) where linksbetween objects are desired.

[0015] Conventional user interfaces are hand written. This includes thelinks between different pieces of data in the databases. Each time sucha link is desired, it must be hand written again. For example, if anorder entry page has been coded to include a link that referencescustomer information, that link has typically been placed by hand. Ifthe order appears elsewhere in the user interface, the link must be handcoded again. Therefore, if a third party integrates an application tothe order object, the order page will not show that information orprovide links to it, because such links have not been hand coded, eventhough there may be a link in a representation of the order object thatis independent of the UI.

SUMMARY OF THE INVENTION

[0016] A system supplies links between objects. A link service receivesa link request from a client. The request identifies a source object.The link service aggregates links from link providers for which thesource object is a source of the links, and provides the aggregatedlinks to the client.

[0017] In one embodiment, the link request identifies an instance of thesource object and the link service aggregates links based on theinstance of the source object. In another embodiment, the link requestidentifies the type of the source object and the link service aggregatesthe links based on the type.

[0018] Link providers can register with the link service so they canprovide links in response to requests from clients. When a link providerrequests to register with the link service, or another system makes therequest on behalf of the link provider, the link service can query thelink provider to obtain information indicative of the links that thelink provider will provide. Traversal of links yields a link result fromthe link providers. The traversal result can be a destination object,which is the destination of the link, or an action, or a combination ofan action and a destination object (or other targets) which isrepresented by the link.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019]FIG. 1 is a block diagram of one embodiment of anobject-relational data storage system.

[0020]FIG. 2 is a block diagram of an environment in which the presentinvention can be used.

[0021]FIG. 3 is a block diagram of a hypermedia service system inaccordance with one embodiment of the present invention.

[0022]FIG. 4 is a flow diagram illustrating how link requests areprocessed by the hypermedia service system in accordance with oneembodiment of the present invention.

[0023]FIG. 5 is an illustration of an exemplary user interface.

[0024]FIG. 6 is a flow diagram illustrating how links are traversed bythe system in accordance with one embodiment of the present invention.

[0025]FIG. 7 is a flow diagram illustrating how hypermedia providers areregistered in accordance with one embodiment of the present invention.

[0026]FIG. 8 shows an association between objects.

[0027]FIG. 9 is a block diagram illustrating another embodiment of ahypermedia system.

[0028]FIG. 10 is a flow diagram illustrating the operation of the systemshown in FIG. 9.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

[0029] The present invention relates to maintaining links betweenobjects. In one exemplary embodiment, the links are between objects inan object-relational (O-R) database, although the objects need not bestored in a database system at all, and the present invention can stillprovide benefits. However, for the sake of the present example, prior todiscussing details of the present invention, an environment in which theinvention may be used will be discussed

[0030]FIG. 1 is a block diagram illustrating one embodiment of a datastorage and accessing system 10 in accordance with the presentinvention. System 10 includes data access system (or entity persistencesystem)12, relational data store mechanism 14, relational database 16,and class-table mapping 18. System 10 is illustratively anobject-relational (O-R) data storage system in which stored data can bereferred to in terms of entities (or objects) and their properties,rather than elements of the data base schema, such as tables andcolumns. FIG. 1 illustrates one mechanism for doing this.

[0031] As shown in FIG. 1, the data can be organized in terms ofentities 20 (which is used interchangeably herein with the termobjects). Each entity illustratively includes a metadata portion 22 anda remaining attributes portion 24. The metadata portion 22 describes theentity 20, while the remaining attributes 24 define further attributesof entity 20, such as the data stored therein. Each of the attributes inentity 20 is mapped to a corresponding entity table 26 and a specificcolumn 28 in a given entity table 26.

[0032] Data access system 12 can receive forms of a request such as aquery 30 which specifies an entity, or portions of an entity or group ofentities, to be retrieved. Query 30 can illustratively be expressed interms of objects (“entities”) and properties rather than in terms oftables and columns. The particular manner in which queries are expresseddoes not form part of the present invention.

[0033] Data access system 12 receives the query 30 and accessesclass-table mapping 18. In this way, data access system 12 can determinethe location of the data for the entities identified by query 30. Dataaccess system 12 includes a translator 13 that translates query 30 intoa relational database query 32 which is suitable for input to relationaldata store mechanism 14. In one illustrative embodiment, relational datastore mechanism 14 is a server that operates according to the SQLprogramming language in accessing relational database 16. Therefore,data access system 12 receives queries 30 in terms of objects andtranslates those queries into an appropriate relational database query32 that is then provided to the data store mechanism (or server) 14which actually accesses the data in relational database 16.

[0034] Relational data store mechanism 14 retrieves the requested dataand returns it in the form of relational database results 34. Theresults are returned to data access system 12 which then formulates therelational database results 34 into a requested result set 36. In oneillustrative embodiment, result set 36 is requested in query 30. Query30 may request that the results be output in the form of one or moreobjects or simply as a data set. In any case, data access system 12arranges the relational database results 34 into the proper format andoutputs them as result set 36.

[0035]FIG. 2 illustrates an example of a suitable computing systemenvironment 100 on which the invention may be implemented. The computingsystem environment 100 is only one example of a suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of the invention. Neither should thecomputing environment 100 be interpreted as having any dependency orrequirement relating to any one or combination of components illustratedin the exemplary operating environment 100.

[0036] The invention is operational with numerous other general purposeor special purpose computing system environments or configurations.Examples of well known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

[0037] The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

[0038] With reference to FIG. 2, an exemplary system for implementingthe invention includes a general purpose computing device in the form ofa computer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus also known as Mezzanine bus.

[0039] Computer 110 typically includes a variety of computer readablemedia. Computer readable media can be any available media that can beaccessed by computer 110 and includes both volatile and nonvolatilemedia, removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 100. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier WAVor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, FR,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

[0040] The system memory 130 includes computer storage media in the formof volatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during startup, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way o example, and notlimitation, FIG. 2 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

[0041] The computer 110 may also include other removable/non-removablevolatile/nonvolatile computer storage media. By way of example only,FIG. 2 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156 such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

[0042] The drives and their associated computer storage media discussedabove and illustrated in FIG. 2, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 2, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies.

[0043] A user may enter commands and information into the computer 110through input devices such as a keyboard 162, a microphone 163, and apointing device 161, such as a mouse, trackball or touch pad. Otherinput devices (not shown) may include a joystick, game pad, satellitedish, scanner, or the like. These and other input devices are oftenconnected to the processing unit 120 through a user input interface 160that is coupled to the system bus, but may be connected by otherinterface and bus structures, such as a parallel port, game port or auniversal serial bus (USB). A monitor 191 or other type of displaydevice is also connected to the system bus 121 via an interface, such asa video interface 190. In addition to the monitor, computers may alsoinclude other peripheral output devices such as speakers 197 and printer196, which may be connected through an output peripheral interface 190.

[0044] The computer 110 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 180. The remote computer 180 may be a personal computer, ahand-held device, a server, a router, a network PC, a peer device orother common network node, and typically includes many or all of theelements described above relative to the computer 110. The logicalconnections depicted in FIG. 2 include a local area network (LAN) 171and a wide area network (WAN) 173, but may also include other networks.Such networking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

[0045] When used in a LAN networking environment, the computer 110 isconnected to the LAN 171 through a network interface or adapter 170.When used in a WAN networking environment, the computer 110 typicallyincludes a modem 172 or other means for establishing communications overthe WAN 173, such as the Internet. The modem 172, which may be internalor external, may be connected to the system bus 121 via the user-inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 2 illustrates remoteapplication programs 185 as residing on remote computer 180. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

[0046] It should be noted that the present invention can be carried outon a computer system such as that described with respect to FIG. 2.However, the present invention can be carried out on a server, acomputer devoted to message handling, or on a distributed system inwhich different portions of the present invention are carried out ondifferent parts of the distributed computing system.

[0047] As stated in the background, conventional user interfaces havetraditionally had any links between objects hand coded. This presents anumber of disadvantages. One aspect of the present invention is a systemfor creating links among objects or entities based on logicalrelationships between those objects, when no physical relationshipnecessarily exists. One embodiment of the invention allows the logicalrelationships among such entities to be surfaced as links in ahyperspace, thus making the entities themselves the nodes of thehyperspace.

[0048] In general, “hypermedia” is referred to as a mechanism fornavigating a hyperspace which is comprised of a set of nodes and thehypermedia links that join those nodes. One embodiment of a hypermediaarchitecture is illustrated in FIG. 3. The hypermedia architecture 200shows a client 202 that communicates with hypermedia service 204.Hypermedia service 204 accesses a provider register 206 and alsocommunicates with a set of hypermedia providers 208, 210 and 212.Hypermedia service (HMS) 204 is illustratively the central point whereclients 202 request hypermedia (i.e., hypermedia links or simply links).Hypermedia providers 208-212 are registered with HMS 204. Providers208-212 are the points at which the links are actually created. Newproviders 208-212 can be registered with HMS 204, thus allowingextensibility.

[0049] The data that is transferred between client 202 and HMS 204, andbetween HMS 204 and providers 208-212 conforms, in one illustrativeembodiment, to an XML schema attached as an exhibit hereto. Thedefinition of a “link” in the schema includes a link category. Linkcategories are discussed in greater detail below. Suffice it to say fornow that new categories may be defined by a hypermedia provider, thusallowing additional extensibility.

[0050]FIG. 4 is a flow diagram better illustrating how a client 202requests links from hypermedia system 200, and it will be described inconjunction with FIG. 3. In one embodiment, the HMS 204 and linkproviders 208-212 are objects that expose application programminginterfaces (APIs) having methods to accomplish the functionalitydescribed. The specific details of the API are described in greaterdetail in the appendix hereto. Assume that client 200 is displaying alist of customer entities (where the term “entities” is usedinterchangeably with the term “object”). Assume also that the clientwishes to display a set of links to the user for possible traversal.Client 202 first generates a request for links in terms of a source node(i.e., a source entity or a source object). In this example, the clientwould request the links for the customer object. The request alsoillustratively specifies which categories of links to be retrieved. Thelinks can represent relationships between nodes, as well as actions thatcan be performed on nodes, or any other destinations specified.

[0051] There are three types of links that can be retrieved: classlinks, instance links and instance specific links. Class links have thecontext of a class. They represent either a relationship to adestination node, or an action that can be performed. A class linkprovides information that is indicative of where a client can traverseto, or what operations can be performed, as they pertain to a particularclass.

[0052] Instance and instance specific links have the context of aninstance. The difference between the two types is that instance specificlinks are directly tied to a specific instance of an entity (or object),and instance links are tied to a class, but an instance of that classmust be specified in order to traverse the link. An instance or instancespecific link provides information indicative of where the client cantraverse to, and what operations can be performed, with the particularinstance being examined.

[0053] All three types of links can be traversed, which is discussed ingreater detail below with respect to FIG. 6. Traversal returns thedestination node of the link. If the link represents an action,traversal performs the action the link represents, and may or may notreturn a destination node.

[0054] In accordance with one embodiment of the present invention, thetype of link is not the only manner in which links may be grouped. Linksalso illustratively belong to a link category. One example of a linkcategory is a metamodel category. This is described in greater detailbelow. Briefly, however, links that belong to this link categoryrepresent associations between entities. These associations are capturedin the metamodel (or object model) of the system.

[0055] In addition to being a grouping mechanism, a link category alsodefines a protocol that is followed by the particular providers 208-212that supplied the link. The link category gives client 202 an indicationof what type of information the link represents, and what type of objectwill result from traversal of the link. All links of the same categorycan be handled in the same manner. In this way, client 202 is able todetermine how to handle a link based on the link category to which itbelongs.

[0056] Therefore, client 202 may generate the hypermedia request byrequesting class, instance, or instance specific links, or a combinationof these. The client 202 can also specify a set of link categories, andonly links from those categories will be returned. If no category isspecified, links from all categories will be returned. In any case, onceclient 202 has generated the request for links, and identified a nodewhich will serve as the source of the link, it provides the request toHMS 204. Generating the request and providing it to HMS 204 is indicatedby blocks 214 and 216 in FIG. 4.

[0057] HMS 204 then checks register 206 for information to identify theparticular providers 208-212 that provide links that have, as a sourcenode, the node identified by client 202 as the source of the links. Thisis indicated by block 218. In other words, during the registrationprocess, providers 208-212 provided HMS 204 with information about thelink categories, link types, and node classes for which the providerprovides links. This information is stored in register 206. Therefore,when HMS 204 receives a request from client 202, it checks register 206to determine which providers it should access.

[0058] HMS 204 then forwards the request generated by client 202 to theidentified providers 208-212 which will provide links having the sourcenode identified by client 202 as the source of the link. This isindicated by block 220.

[0059] The providers which receive the request, in turn, return therequested links to HMS 204. This is indicated by block 222. HMS 204 thenaggregates all of the links from the providers 208-212 which haveresponded with links, and returns those links to client 202. This isindicated by block 224 in FIG. 4.

[0060]FIG. 5 shows an exemplary user interface where links have alreadybeen requested. In FIG. 5, the user interface generator that generatesdisplay 300 is currently rendering a customer list that displaysinformation about a plurality of customer objects 302, 304, 306 and 308.When the user selects a certain customer object, the user interfacegenerates a request requesting links from HMS 204 where the selectedcustomer object 302 is the source link. HMS 204 goes through the processdescribed with respect to FIG. 4 and returns a set of links for whichcustomer entity 302 (which can also be referred to as customer node 302)is the source node. The user interface generating the display can thendisplay the links 310 as desired. In the example shown in FIG. 5, thelinks for which customer node 302 is the source node include an addresslink identifying an Address node associated with customer node 302, anorders link which links to an Orders node corresponding to customer node302 and a general information link which links to a General Informationnode corresponding to customer node 302.

[0061] In one example, to traverse one of the links 310, the user simplyselects it (such as by clicking on it with the mouse cursor). FIG. 6 isa flow diagram illustrating what happens when a link is traversed. Afterbeing selected by the user, client 202 sends the link, along with thetraversal request, to HMS 204. This is indicated by block 350 in FIG. 6.The link provided by client 202 is illustratively a class link or aninstance specific link.

[0062] HMS 204 then identifies the particular provider 208-212 thatprovided the link. This is indicated by block 352. The specific linkssupplied by the providers in response to requests is maintained by HMS204 by adding this information to the link during the hypermediarequest. This information is then examined during a traversal request.Therefore, HMS 204 can identify the provider which supplied the link.

[0063] HMS 204 then forwards the traversal request and link to theidentified provider. This is indicated by block 354.

[0064] The provider traverses the link, returning traversal results toHMS 204. This is indicated by block 356. The traversal results caninclude a destination node, which is the destination of the link, orperformance of an action represented by the link or both, or othertargets represented by the link. For example, if the link represents therelationship between a customer and a query of the customer's orders,traversing the link entails the provider returning the query (which isan entity, like the customer), not the results of executing the query.Likewise, if the link represents the relationship between a customer anda URL of a particular web page containing a map of the customer'saddress, traversing the link returns the URL, it does not open a browserwindow displaying the page pointed to by the URL. In that example, thelink does contain a destination (the URL), but the destination is not anentity or an action. Thus, the traversal result may return an entity,some result which is not an entity, or there may be no substantiveresult returned. If the link represents an action, traversing the linkperforms the action and the result may indicate this. Combinations ofthese types of results can occur as well.

[0065] HMS 204, in turn, returns the traversal results to client 202.This is indicated by block 358.

[0066] Client 202 illustratively includes a handler that handles thetraversal results. For example, if the traversal returns a query, theclient handler executes that query against the database and displays theresults to the user. If the query returns a URL, the client handleropens a browser window displaying the page pointed to by the URL, etc.Handling the traversal results at the client is indicated by block 360in FIG. 6.

[0067]FIG. 7 is a flow diagram illustrating how a provider is registeredwith HMS 204. First, HMS 204 receives a request to register a provider.This is indicated by block 362.

[0068] HMS 204 then checks the security of the requester. This isindicated by block 364. This involves determining whether the requesterhas authorization to register a provider and can be done in any knownway. This is indicated by block 366.

[0069] HMS 204 then requests information from the provider about thelink categories, link types and node classes for which the providerprovides links. This is indicated by block 368.

[0070] The provider returns the information, along with a versionidentifier. This is indicated by block 370.

[0071] HMS 204 then caches the information in provider register 206, andinformation confirming the success of the registration is returned tothe requester. This is indicated by block 372. HMS 204 is then inposition to receive requests for links provided by the newly registeredprovider.

[0072] A number of other features of the present invention should benoted. It can be seen from the architecture that any number of providerscan be added, at any time. Third party providers who integrateapplications to the entities or objects stored in the database can beadded and links to those third party applications will automatically bereturned by HMS 204, so long as an appropriate provider is registeredwith HMS 204.

[0073] Also, third parties can define new link categories for whichtheir providers will provide links. HMS 204 can operate with noknowledge about what the links are, only knowing that the provider willprovide those links. The same is true for new links. An existingprovider can add new links and they will be provided when requested. Thedeveloper thus need not hand code the links into the system. In oneillustrative embodiment, the providers simply need to implement aninterface known to HMS 204, such as those described in the Appendixhereto.

[0074] In another illustrative embodiment, the interface implemented byHMS 204 derives from the interface implemented by the providers.Therefore, each HMS 204 can also be a provider and can thus be operablyconnected to another HMS 204.

[0075] Also, HMS 204 can be implemented both as an XML web service andas a class which can be called directly if client 202 resides on thesame server as HMS 204. The providers can also be either deployedremotely as XML web services or on the same server as HMS 204.

[0076] It can thus be seen that, in accordance with one embodiment ofthe present invention, the links are requested based on object types (orobject classes) or specific object instances. The presentation of thenodes is decoupled from the nodes themselves. The nodes are instances ofobjects rather than presentation elements, such as web pages. Thisallows client 202 to process or handle the destination node of the linkin any manner it wishes.

[0077] FIGS. 8-10 illustrate yet another embodiment of the presentinvention. In that embodiment, one of providers 208-212 provides linksbetween associated objects based on association metadata. In otherwords, when developing an application, it is common for a set of objects(such as business objects or entities in a business application) to bedefined. Such objects in a business application may include, forexample, a “Customer” object, a “SalesPerson” object and an “Order”object. These objects (entities) are interrelated through differentassociations. For instance, an “Order” has both a “Customer” and a“SalesPerson” associated with it. Since these associations exist in theproblem domain of the application, they are associations that the enduser typically understands. Therefore, it may be beneficial to allow theend user to navigate between these associations.

[0078] The information that defines these associations is captured in ametamodel (or object model) of the applications as they are beingdeveloped. This information is typically stored as metadata. Forexample, FIG. 8 depicts a relationship between an “Order” entity and a“Customer” entity that is modeled during the application developmentprocess.

[0079] There are known tools which can be run against object modelsgenerated during development of an application. Such tools compile themodels into association metadata. In accordance with an illustrativeembodiment of the invention, this is done and the association metadatais stored.

[0080]FIG. 9 is a block diagram of an embodiment of hypermedia system201 that takes advantage of the stored association metadata. A number ofthe items shown in FIG. 9 are similar to those shown in FIG. 3 and aresimilarly numbered. However, FIG. 9 shows that system 201 also includesa metadata hypermedia provider 400 which is connected to a metadatastore 402.

[0081] The metadata associations developed during the applicationdevelopment process (such as the information shown in FIG. 8 whichillustrates an association between an “Order” entity and a “Customer”entity) is stored in metadata store 402. FIG. 10 is a flow diagramillustrating the operation of system 201 in accordance with oneembodiment of the present invention, and will be described inconjunction with FIG. 9.

[0082] It is assumed that metadata hypermedia provider 400 has properlyregistered with HMS 204 and its link and identification data resides inprovider register 206. Client 202 first generates a hypermedia request(or link request) specifying which objects are the source of the linkssought, and which categories of links are to be retrieved. This requestis received by HMS 204. This is indicated by block 404 in FIG. 10. HMS204 then forwards the request on to the appropriate providers, which inthis case will include metadata hypermedia provider 400. This isindicated by block 406.

[0083] Provider 400 analyzes association information contained inmetadata store 402. One illustrative design of metadata hypermediaprovider 400 is discussed in greater detail in the Appendix hereto.Briefly, however, provider 400 examines each association in metadatastore 402 which has been requested and determines whether the user hasrights to access the associated entities. Provider 400 can determinewhether the user has rights to access the associated entities byaccessing a security subsystem, or in any other suitable way. Accessingsecurity does not form part of the present invention. Provider 400 thencreates a link for each association for which the user has access, andplaces association information in the link. This is indicated by block408.

[0084] Provider 400 identifies (using terminology defined by the UnifiedModeling Language (UML)) simple associations and compositionassociations; these can have a variety of cardinalities, such as 1-1,1-many or many-many relationships. Provider 400 also identifiesinheritance associations. For each association located by provider 400,provider 400 creates a link between the source node and the associatednode. This is indicated by block 410.

[0085] The links are returned from provider 400 to HMS 204 as indicatedby block 412, and HMS 204 aggregates all returned links and forwardsthem on to client 202. This is indicated by block 414. In oneembodiment, provider 400 does not return the associated node, butinstead returns a query whose results, if executed, include only theassociated node.

[0086] Although the present invention has been described with referenceto particular embodiments, workers skilled in the art will recognizethat changes may be made in form and detail without departing from thespirit and scope of the invention.

What is claimed is:
 1. A system for supplying links between objectscomprising: a link service receiving a link request from a client, thelink request identifying a source object, the link service aggregatinglinks from link providers for which the source object is a source of thelinks and providing the aggregated links to the client.
 2. The system ofclaim 1 wherein the link request identifies an instance of the sourceobject and wherein the link service aggregates the links based on theinstance of the source object.
 3. The system of claim 1 wherein the linkrequest identifies the class of the source object and wherein the linkservice aggregates the links based on the class of the source object. 4.The system of claim 1 and further comprising: a link provider operablycoupled to the link service, the link service requesting links havingthe source object as the source of the links from the link provider. 5.The system of claim 4 and further comprising: a provider register,operably coupled to the link service, storing register informationcorresponding to the provider, the register information being indicativeof links provided by the link provider.
 6. The system of claim 5 whereinthe register information is indicative of source objects for which thelink provider provides links.
 7. The system of claim 6 wherein theregister information is indicative of classes of objects for which thelink provider provides links.
 8. The system of claim 6 wherein theregister information is indicative of instances of objects for which thelink provider provides links.
 9. The system of claim 6 and furthercomprising: a plurality of link providers, the provider register storingregister information for each of the plurality of link providers. 10.The system of claim 9 wherein the link service accesses the providerregister to identify link providers from which to request links, basedon the identified source object.
 11. The system of claim 10 wherein thelink service is configured to receive a traversal request from theclient, the traversal request identifying a link to traverse.
 12. Thesystem of claim 11 wherein the link service is configured to determinewhich link provider provided the link and to request that link providerto traverse the link, the link provider returning a traversal result.13. The system of claim 12 wherein the link represents an associationwith a destination object and wherein the traversal result comprises thedestination object.
 14. The system of claim 12 wherein the linkrepresents an action and wherein the traversal result comprises anindication that the link provider has taken the action.
 15. The systemof claim 12 wherein the link belongs to a link category and wherein thetraversal result comprises: a destination object belonging to the linkcategory.
 16. The system of claim 15 wherein the link category isdefined by a link provider.
 17. The system of claim 12 wherein the linkservice returns the traversal result to the client.
 18. The system ofclaim 17 and further comprising: a handler operably coupled to theclient and configured to handle the traversal result.
 19. The system ofclaim 5 wherein the link service is configured to receive a registrationrequest for an additional link provider.
 20. The system of claim 19wherein the link service queries the additional link provider forregister information corresponding to the additional link provider andstores the register information in the provider register.
 21. A methodof maintaining links between objects comprising: receiving a linkrequest at a link service from a client, the link request identifying anobject that is a source object in links being requested; requestinglinks from a plurality of providers, based on the identified object;aggregating links from the providers, at the link service; and returningthe aggregated links to the client.
 22. The method of claim 21 whereinthe link request identifies an instance of the source object and whereinrequesting comprises: requesting links based on the instance of thesource object.
 23. The method of claim 22 wherein the link requestidentifies a specific instance of the source object and whereinrequesting comprises: requesting links based on the specific instance ofthe source object.
 24. The method of claim 21 wherein the link requestidentifies a class of the source object and wherein requestingcomprises: requesting links based on the class of the source object. 25.The system of claim 21 wherein requesting comprises: accessing aprovider register storing register information corresponding to theproviders, the register information being indicative of links providedby the providers.
 26. The method of claim 21 and further comprising:receiving a traversal request from the client, the traversal requestidentifying a link to traverse.
 27. The method of claim 26 and furthercomprising: determining which link provider provided the link; andrequesting that link provider to traverse the link, the link providerreturning a traversal result.
 28. The method of claim 27 wherein thelink represents a destination object and further comprising: returningthe destination object to the client.
 29. The method of claim 27 whereinthe link represents an action and further comprising: returning anindication that the link provider has taken the action to the client.30. The method of claim 21 and further comprising: receiving aregistration request for an additional link provider.
 31. The method ofclaim 30 and further comprising: querying the additional link providerfor register information corresponding to the additional link provider;and storing the register information.
 32. A method of maintaininghypermedia links, comprising: receiving, at a hypermedia service, aregistration request for a link provider that provides links betweenobjects; querying the link provider for register information indicativeof source nodes for which the link provider provides links; and storingthe register information.
 33. The method of claim 32 wherein queryingcomprises: querying the link provider for object classes for which thelink provider provides links.
 34. The method of claim 32 whereinquerying comprises: querying the link provider for instances of objectsfor which the link provider provides links.
 35. A method of traversinglinks between objects the method comprising: receiving, at a hypermediaservice, a traversal request from a client, the traversal requestidentifying a link to traverse; determining which of a plurality of linkproviders provided the link; and requesting that link provider totraverse the link, the link provider returning a traversal result. 36.The method of claim 35 wherein the link represents a destination objectand further comprising: returning the destination object to the client.37. The method of claim 35 wherein the link represents an action andfurther comprising: returning an indication that the link provider hastaken the action to the client.
 38. The method of claim 35 and furthercomprising: returning the traversal result to the client; and the clientreturning the traversal result to a handler that handles the traversalresult.